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SECURITY ARCHITECTURE WITH 
ENVIRONMENT SENSITIVE CREDENTIAL 
SUFFICIENCY EVALUATION 

BACKGROUND 
L Field of the Invention 

The invention relates to information security, and more 
particularly, to systems and method for improving the secu- 
rity of information transactions over networks. 

2. Description of the Related Art 

The internet has become an important medium for infor- 
mation services and electronic commerce. As the internet 
has been commercialized, organizations initially established 
their presence in cyberspace by making information 
(typically static, non-sensitive promotional information) 
available on resources well removed from the operational 
infrastructure of the organization. Security issues were often 
addressed by isolating publicly accessible resources (e.g., 
web servers) from more sensitive assets using firewall 
techniques. As long as the publicly accessible information 
and resources were relatively non-sensitive and user inter- 
actions with such information and resources was not mission 
critical, relatively simple firewall techniques were adequate. 
Though information and resources outside the firewall were 
at risk, the risk could generally be limited to non-proprietary 
information that was easily replaceable if compromised. 
Proprietary information and systems critical to day-to-day 
operations were sheltered behind the firewall and informa- 
tion flows across the firewall were filtered to exclude all but 
the comparatively non-threatening services such as elec- 
tronic mail. 

However, as the internet has become more pervasive, and 
as the sophistication of tools and techniques has increased, 
several aspects of the security environment have changed 
dramatically. First, businesses have recognized the power of 
information transactions that more tightly couple to opera- 
tional data systems, such as order processing, inventory, 
payment systems, etc. Such transactions include electronic 
commerce with direct purchasers or consumers (e.g., 
browsing, selecting and purchasing of books by members of 
the public from an on-line bookseller) as well as supply 
chain and/or business partner interactions (e.g., automated 
just-in-time inventory management, customer-specific 
pricing, availability and order status information, etc.). 
Commercially relevant transactions increasingly require 
information flows to and from secure operational systems. 
Second, even information-only services are increasingly 
mission-critical to their providers. Corporate image can be 
adversely affected by unavailability of, or degradation 
access to, otherwise non-sensitive information such as cus- 
tomer support information, product upgrades, or marketing 
and product information. Because many businesses rely 
heavily on such facilities, both unauthorized modification 
and denial of service represent an increasing threat. 

Individual information service or transaction system typi- 
cally exhibit differing security requirements. While it is 
possible to field individualized security solutions for each 
information service or transaction system, individualized 
solutions make it difficult to maintain a uniform security 
policy across a set of applications or resources. Furthermore, 
individualized solutions tend to foster incompatible security 
islands within what would ideally be presented to consumers 
or business partners as a single, integrated enterprise. For 
example, a user that has already been authenticated for 
access to an order processing system may unnecessarily be 
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re -authenticated when accessing an order status system. 
Worse still, a set of individualized solutions is typically only 
as good as the weakest solution. A weak solution may allow 
an enterprise to be compromised through a low security 

5 entry point. 

Another problem with individualized solutions is a veri- 
table explosion in the number of access controls confronting 
a user. As more and more business is conducted using 
computer systems, users are confronted with multiple iden- 

10 tifiers and passwords for various systems, resources or levels 
of access. Administrators are faced with the huge problem of 
issuing, tracking and revoking the identifiers associated with 
their users. As the "user" community grows to include 
vendors, customers, potential customers, consultants and 

15 others in addition to employees, a huge "id explosion" faces 
administrators. Furthermore, as individual users are them- 
selves confronted with large numbers of identifiers and 
passwords, adherence to organizational security policies 
such as password restrictions and requirements (e.g., length, 

20 character and/or case complexity, robustness to dictionary or 
easily-ascertainable information attack, frequency of update, 
etc.) may be reduced. As users acquire more passwords — 
some individuals may have 50 or more — they cannot help 
but write down or create easy-to-remember, and easy-to- 

25 compromise, passwords. 

SUMMARY 

Accordingly, a security architecture has been developed 
in which a single sign-on is provided for multiple informa- 

30 tion resources. Rather than specifying a single authentica- 
tion scheme for all information resources, security architec- 
tures in accordance with some embodiments of the present 
invention associate trust-level requirements with informa- 
tion resources. Authentication schemes (e.g., those based on 

35 passwords, certificates, biometric techniques, smart cards, 
etc.) are associated with trust levels and environmental 
parameters. In one configuration, a log-on service obtains 
credentials for an entity commensurate with the trust-level 
requirement(s) of an information resource (or information 

40 resources) to be accessed and with environment parameters 
that affect the sufficiency of a given credential type. Once 
credentials have been obtained for an entity and have been 
authenticated to a given trust level, access is granted, 
without the need for further credentials and authentication, 

45 to information resources for which the trust level is sufficient 
given a current session environment. In some configurations, 
credential insufficiency may be remedied by a session con- 
tinuity preserving credential upgrade. 
By including environment information in a security 

50 policy, facilities in accordance with some embodiments of 
the present invention advantageously allow temporal, 
locational, connection type and/or client capabilities-related 
information to affect the sufficiency of a given credential 
type (and associated authentication scheme) for access to a 

55 particular information resource. In some configurations, 
time of access, originating location (physical or network) 
and/or connection type form a risk profile that can be 
factored into credential type sufficiency. In some 
configurations, changing environmental parameters may 

60 cause a previously sufficient credential to become insuffi- 
cient. Alternatively, an authenticated credential previously 
insufficient for access at a given trust level may be sufficient 
based on a changed or more fully parameterized session 
environment. In some configurations, the use of session 

65 tracking facilites (e.g., the information content of session 
tokens) can be tailored to environmental parameters (e.g., 
connection type or location). Similarly, capabilities of a 
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particular client entity (e.g., browser support for 128-bit 
cipher or availablity of a fingerprint scanner or card reader) 
may affect the availability or sufficiency of particular 
authentication schemes to achieve a desired trust level. Of 
course, not all advantages need be provided in any given 5 
implementation. 

In one embodiment in accordance with the present 
invention, a method of determining sufficiency of a creden- 
tial type for access to an information resource includes 
establishing a correspondence between a session and an 10 
access request targeting the information resource, establish- 
ing a trust level requirement for access to the information 
resource, and evaluating correspondence of one or more 
credential types with the trust level requirement for access to 
the information resource and with environment information 15 
associated with the session. 

In another embodiment in accordance with the present 
invention, a method of operating a security architecture 
includes matching an access request of a client entity with a 
corresponding session. The access request targets a first of 20 
plural information resources and the session has an associ- 
ated one or more session parameters affecting sufficiency of 
credential types. The method further includes determining a 
set of one or more credential types sufficient for access to the 
first information resource. The determining is based, at least 25 
in part, on the one or more session parameters. If an 
authenticated credential associated with the session is of one 
of the sufficient credential types, then access to the first 
information resource is allowed. Otherwise, a new credential 
is obtaining, the client is authenticated entity thereby, and 30 
access to the first information resource is allowed. The 
obtained credential is of one of the sufficient credential 
types. 

In still another embodiment in accordance with the 35 
present invention, an information system includes plural 
information resources hosted on one or more servers 
coupled via a communication network to a client entity and 
an access control facility common to the plural information 
resources. The plural information resources have individu- 4Q 
alized authentication requirements and the common access 
control facility obtains a credential for the client entity and 
authenticates the client entity thereby. In response to a 
request for access to a first of the information resources, the 
common access control facility evaluates, based in part on 45 
current parameters of a corresponding persistent session, 
sufficiency of associated authenticated credentials for access 
to the first information resource. 

In still yet another embodiment in accordance with the 
present invention, an access control facility for providing a 50 
single sign-on for sessions that potentially include accesses 
to plural information resources having differing security 
requirements includes an application proxy and means 
responsive to the application proxy for evaluating suffi- 
ciency of credential types based on then current parameters 55 
of the session and on a trust level requirement of the targeted 
information resource. The application proxy configured for 
receiving an access request targeting one of the information 
resources, associating the access request with a session, and 
selectively proxying the access request if at least one suf- 60 
ficient credential is associated with the session. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention may be better understood, and its 
numerous objects, features, and advantages made apparent 65 
to those skilled in the art by referencing the accompanying 
drawings. 
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FIG. 1 is a block diagram illustrating information flows 
between components in a security architecture with envi- 
ronment sensitive credential sufficiency evaluation in accor- 
dance with an exemplary embodiment of the present inven- 
tion. 

FIG. 2 is a flow chart illustrating operation of a security 
architecture with environment sensitive credential suffi- 
ciency evaluation in accordance with an exemplary embodi- 
ment of the present invention. 

FIG. 3 illustrates interactions between functional compo- 
nents in a functional decomposition of a security architec- 
ture with environment sensitive credential sufficiency evalu- 
ation in accordance with an exemplary embodiment of the 
present invention. 

FIG. 4 illustrates relations between login credentials, 
session credentials and a cookie encoding of a session token 
in accordance with an exemplary embodiment of the present 
invention. 

The use of the same reference symbols in different draw- 
ings indicates similar or identical items. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENT^) 

Some terminology used in this specification has meaning 
particular to the context of embodiments described herein. 
Therefore, to aid persons of ordinary skill in the art in 
understanding the full scope of the invention, some of that 
terminology is now defined. 
Glossary 

Access Management: Systems, methods and techniques 
for controlling use of information resources. Typically, 
access management systems employ both authentication and 
authorization to control access to information resources. 

Authentication: A process used to verify the identity of an 
entity. As typically implemented, an authentication method 
is employed to verify the identity of a user or object based 
on a credential supplied by the user or object. 

Authorization: A process for determining whether an 
identity is permitted to perform some action, such as access- 
ing a resource. Typically, an identity will be authenticated, 
though in some configurations certain identities need not be. 

Credential: Evidence of identity used to authenticate an 
entity. Exemplary credentials types include passwords, cer- 
tificates or other encrypted indicia based on asymmetric, 
symmetric, public, private, or secret key technologies, one- 
time passwords, biometric indicia such as by retinal scan, 
voice print, finger print, etc., and possession based indicia 
such as smart cards, Enigma cards, keys, etc. In some 
realizations, credentials may be associated with users, 
sessions, functional objects, etc. 

Digital Signature: A transformation of a message using an 
asymmetric cryptosystem such that a person having the 
initial message and the signer's public key can accurately 
determine whether the transformation was created using the 
private key that corresponds to the signer's public key and 
whether the message has been altered since the transforma- 
tion was made. 

Entity: A user or object, including data objects and/or 
functional objects such as applications, components, 
modules, services, processes, threads, etc., as well as instan- 
tiations thereof. In some configurations, only user entities 
(typically, the human principal interacting with a software 
program or on whose behalf a software agent purports to act) 
are considered. In other configurations, entities include 
functional objects without an associated human principal. 
The identity of an entity may be authenticated using a 
credential. 
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Session: A period and collection of states spanning one or authorization component 140 to obtain authorization for 
more interactions between an entity and an information access to a particular requested enterprise application or 
environment. As used herein a session may span multiple information resource by the requesting entity (e.g., the 
interactions with multiple resources of the information envi- browser user). If the entity requesting access has not yet 
ronment and, in some configurations, may span multiple 5 b een authenticated to the trust level required for the par- 
information access protocols (e.g., HTTP, FTP, telnet, etc.). licular access to the particular enterprise application or 
A session has a beginning and an end. During its existence, information resource requested, authorization component 
a session has state. As used herein, the term session connotes 140 may iDdicate thal me access requcst ^ t0 5e redir ected 
a greater persistence than as sometimes used to describe the lQ { - component 12 0 so that login credentials may be 
period of a "session layer protocol ^interaction, which in the 1Q obuined and authenticated to a rticular trust level If> on 

short lived™ ^ ' SU ° h ™ H1TP ' 15 gCneraUy Very the other hand, login credentials have already been obtained 

SingleSign-on Security Architecture for L the fasting eDt ^ ™ d the requesting entity has been 

FIG. 1 provides an overview of major interactions authenticated using the obtained credentials such that the 

between components for an exemplary security architecture rec ? uired trust level has been achieved, the access will 

in accordance with the present invention. As illustrated in 15 typically be allowed without the need for further login 

FIG. 1, a client application, e.g., a browser 170 operated by credentials and authentication. In certain circumstances, 

a user, interacts with the security architecture via a gate- authorization component 140 may indicate that the access is 

keeper and entry handler component 110 and a login com- to be refused. For example, authorization component 140 

ponent 120. Gatekeeper and entry handler component 110 may be programmed to perform more stringent testing 

provides an entry point for external client applications 20 beyond a trust level requirement. In an exemplary enterprise 

requesting access to enterprise applications and/or resources tool configuration, a desired security policy may dictate that 

190, including e.g., information resources 191, 192 . . . 193, a salary tool is accessible only from with a company's 

for which access management is provided by the security internal network. No level of authenticated trust may be 

architecture. Using facilities provided by a session manage- sufficient to access such a tool from outside company 

ment component 160, an authorization component 140, an 25 network. To facilitate implementation of such a security 

authentication component 130, an identification component policy, authorization component 140 could refuse access 

150, and login component 120, the gatekeeper/entry handler based on environment parameters indicating a session origi- 

component 110 allows, redirects or refuses access requests nating outside the company's internal network, 

in accordance with a security policy. Of note, in certain embodiments in accordance with the 

Individual information resources typically have differing 30 present invention, the mapping of login credential types and 

security requirements. In addition, individual types of access authentication mechanisms to trust levels is influenced by 

to a single information resource may have differing security environment information such as time of request, source of 

requirements. Nonetheless, a given level of security maybe request, connection speed, and/or client application (e.g., 

sufficient for more than one of the information services or browser) environment information. In this way, even with a 

access types. For example, information resource 191 may 35 static set of mapping rules, the set of credential types and 

include a product information service for providing general authentication mechanisms suitable to support a given trust 

information such as product descriptions or data sheets to level may vary based on environment information. In 

the public, while information resource 192 includes an order general, mapping rule dependencies are based on perceived 

processing system for an eCommerce site. Information variations in threat characteristics and/or requesting entity 

resource 193 may include functions for supply chain inter- 40 capabilities. In some embodiments in accordance with the 

actions such as access to inventory information or current present invention, gatekeeper/entry handler component 110 

selling price information. Both the product information is the authority on environment information for a particular 

service and order intake functions of the eCommerce may requesting entity. 

operate with similar security requirements, e.g., allowing In some embodiments, mapping rules may be dynami- 

access by minimally authenticated, non-hostile entities. On 45 cally varied. For example, if a particular login credential 

the other hand, supply chain functions may require a higher type and/or authentication method is deemed insecure (e.g., 

level of security. Order status functions of the order pro- because compromised or because of a changing threat 

cessing system may require a mid-level of security. profile), the trust level mappings can be updated and have 

Login component 120, operating in conjunction with enterprise- wide effect. In addition, several other advantages 

gatekeeper/entry handler component 110 and other compo- 50 are achieved by defining the authentication requirement 

nents of the security architecture, provides a single sign-on interface between enterprise applications and/or resources 

interface for access to enterprise applications and/or and the security architecture in terms of required trust levels, 

resources 190. In an exemplary embodiment, security rather than in terms of particular credential types and 

requirements are expressed in terms of trust levels and login authentication methods. First, single sign-on configurations 

component 120 obtains login credentials for an entity 55 are facilitated using an enterprise-wide credential obtaining, 

requesting access to one of the enterprise applications and/or authentication and session tracking infrastructure. Second, 

resources 190. The login credentials obtained are selected authentication requirements may be enforced uniformly in 

from a set of credential types that, if authenticated, are accordance with an enterprise -wide security policy and with 

sufficient to achieve the trust level requirement of an appli- reduced vulnerability to a lax security implementation by 

cation or information resource to be accessed. Without 60 any particular information resource. Third, credential types 

limitation, typical login credential types and associated and authentication methods can be added, deleted, or 

authentication mechanisms include those based on mapped to a new trust level, all without modification of 

passwords, certificates, biometric techniques, smart cards, enterprise applications and resources. Of course, all advan- 

etc. Other credential types and associated authentication tages need not be achieved in any particular implementation, 

mechanisms are described elsewhere herein. 65 In certain embodiments in accordance with the present 

In some embodiments in accordance with the present invention, a credential upgrade facility is provided. In 

invention, gatekeeper/entry handler component 110 queries response to an access request from an entity for which login 
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credentials have already been obtained and authenticated, 
but for which the obtained and authenticated login creden- 
tials are insufficient for the trust level associated with the 
requested access, authorization component 140 may indicate 
that the access request is to be redirected to login component 
120 so that sufficient login credentials may be obtained and 
authenticated to the required trust level. Of note, credential 
upgrade facilities in accordance with certain embodiments 
of the present invention allow upgrade without loss of 
session continuity. 
Exemplary Configuration 

Referring to FIG. l f an entity (e.g., a browser 170 
operated by a user) interacts with enterprise applications 
and/or resources 190 and the security architecture via a 
gatekeeper/entry handler component 110 and a login com- 
ponent 120. In general, a wide variety of entities, including 
human users operating browser and/or non-browser client 
applications as well as automated agents and systems, may 
interact with enterprise applications and/or resources 190 
and the security architecture as described herein. 
Furthermore, a variety of information resource identification 
schemes, such as by Uniform Resource Locator (URL), 
resource address, identifier or namespace designation, may 
be employed. However, for purposes of illustration and not 
limitation, an exemplary interaction involving a browser and 
information resources identified by URL is described in 
detail. Nonetheless, based on the description herein, persons 
of ordinary skill in the art will appreciate a wide variety of 
configurations in accordance with the present invention in 
which non-browser clients, automated agents or other sys- 
tems interact with enterprise applications and/or resources 
190 and the security architecture using any of a variety of 
information resource identification schemes. 

Focusing then on an exemplary browser-type client entity, 
browser 170 requests access to one or more of enterprise 
applications and/or resources 190 (e.g., information resource 
191) by presenting an URL to gatekeeper/entry handler 
component 110, which acts as a point of entry for client 
entities requesting access to applications and/or resources 
controlled by the security architecture. Gatekeeper/entry 
handler component 110 receives the request as a proxy for 
the requested resource. In some configurations, a combined 
gatekeeper/entry handler instance is provided, while in 
others, separate and/or multiple instances are provided with 
functionally identical interfaces to other components of the 
security architecture. In some configurations, multiple 
instances of entry handler functionality (e.g., interception of 
inbound requests and collection of environment 
information) are provided. For example, one or more 
instances for each of several connection types (e.g., dialup, 
WAN, etc.) may be employed. One or more instances of 
gatekeeper functionality (e.g., allowing access for autho- 
rized requests and otherwise denying or initiating appropri- 
ate responsive action) may also be provided. Configurations 
and functional decompositions suitable to a particular envi- 
ronment and expected load requirements will be appreciated 
by persons of ordinary skill in the art. 

Entry handler functionality (e.g., in gatekeeper/entry han- 
dler component 110) ascertains much of the requesting 
client's environment information. For example, for dial-up 
connections, environment information such as line speed 
and low-level line encryption are ascertained. Additional 
information, such as source number (e.g., from caller id 
information or based on a callback configuration), signaling 
type (e.g., POTS or digital ISDN), etc., may also be 
obtained. For network connections, similar environment 
information (e.g., source network and/or node, Virtual Pri- 
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vate Network (VPN) low-level encryption, etc.) may be 
obtained from incoming requests themselves or based on a 
particular entry point (e.g., a particular router or port). More 
generally, gatekeeper/entry handler component 110 obtains 

5 and/or maintains information such as connect location (if 
ascertainable), temporal information such as request time/ 
date, session start time/date, etc. (preferably in both the 
client entity's frame of reference and the security architec- 
ture or requested information resource's frame of reference, 

10 if location is ascertainable), and client type and/or capabili- 
ties (e.g., browser type and Java Development Kit (JDK) 
level). In some configurations, information on line speed, 
origination point (e.g., inside or outside of a corporate 
network), browser type, encryption capability, number of 

15 hops, latency, system type, etc. may be gathered. Such 
information is used in some configurations for mapping 
particular authentication mechanisms to trust levels and for 
authorization decisions. Environment information is gener- 
ally packaged into a data structure that is associated with a 

20 client session. Other components of the security architecture 
may add additional client environment information, such as 
authentication strength or current trust level. 

Gatekeeper functionality (e.g., in gatekeeper/entry han- 
dler component 110) checks whether a session is already 

25 associated with the incoming request. Although other tech- 
niques are possible, in some configurations in accordance 
with the present invention, gatekeeper/entry handler com- 
ponent 110 checks for the presence of a session token in the 
incoming request. Use of session tokens is described in 

30 greater detail below; however, in short, a session token may 
be any data supplied to the client entity for use in uniquely 
identifying an associated session. In general, preferred ses- 
sion token implementations are cryptographically secured 
and include facilities, such as expiration or mapping to a 

35 particular connection, to limit risk of replay attack and/or 
spoofing. Some session token implementations may encode 
session, principal, and/or trust level information. Some 
session token implementations may employ cookies, URL 
encoding, or other similar techniques for binding to incom- 

40 ing requests. 

In some configurations, session tokens are employed to 
facilitate session continuity and to allow the security archi- 
tecture to associate prior authentication of login credentials 
with an incoming access request. In one utilization, session 

45 tokens are issued to client entities as part of an interaction 
with the security architecture and are thereafter presented 
with access requests. In some configurations, new session 
tokens (each corresponding to a single session) are issued to 
client entity on each credential level change. In other 

50 configurations, a session token may remain the same even as 
credential levels are changed. Session continuity means the 
maintenance of coherent session state across one or more 
interactions between an entity and an information environ- 
ment. 

55 Components of session state (e.g., in some configurations, 
principal id, session id, authenticated trust level, group ids 
and/or roles, creation time, expiration time, etc.) are main- 
tained or advanced throughout the duration of a session. 
Typically, aspects of session state are represented internally 

60 by the security architecture and a session token (e.g., a 
session id encoded in a cryptographically secured session 
token) allows the security architecture to reference into the 
internal representation. However, in some configurations, at 
least some aspects of session state may be represented or 

65 duplicated in the session token. For example, a principal id 
and current trust level are encoded in one realization of a 
cryptographically secured session credential and associated 
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session token or cookie. In general, a variety of facilities, 
such as cookies, can be used to maintain state across a series 
of protocol interactions, such as HTTP transactions, that do 
not otherwise support persistent session state. 

Referring again to FIG. 1, if a session token is present in 5 
the incoming request, gatekeeper/entry handler component 
110 resolves the token to a session object. Alternatively, if no 
session token is present or if a session token is invalid, 
gatekeeper/entry handler component 110 establishes a new 
session (2). In an exemplary configuration in accordance JQ 
with FIG. 1, session management component 160 allocates 
a new session and supplies associated default session cre- 
dentials (2) based on the requested information resource and 
environment information. Note that a session is created 
irrespective of authentication status or identity, although 
some implementations may refuse to even allocate a session 15 
based on particular information resource requests and/or 
environment information. Given a session object, which 
may be resolved from a received session token or newly 
allocated, gatekeeper/entry handler component 110 interacts 
(3, 4) with authorization component 140 to determine 20 
whether the requested access is authorized. For some 
requested accesses and security policies (e.g., anonymous 
ftp access to certain archives), even a session without 
authenticated login credentials (trust level=0) may be autho- 
rized. For others, a more substantial trust level may be 25 
required. 

Gatekeeper/entry handler component 110 supplies autho- 
rization component 140 with an identifier for the requested 
resource (e.g., the requested URL) and an identifier for the 
associated session. Preferably, the associated session iden- 3Q 
tifier is cryptographically secured (e.g., as a signed session 
credential). In some configurations, the signed session cre- 
dential is obtained from the corresponding session object. In 
the case of a pre-existing session, the signed session cre- 
dential may be obtained using a received session token. In 
any case, authorization component 140 receives (3) the 35 
requested resource and session identifiers and responds (4) 
in accordance with the trust level requirement of the 
requested resource. In configurations for which sensitivity to 
a changing environment is desired, environment information 
may also be supplied to authorization component 140. In an 40 
exemplary configuration, authorization component 140 
responds with an ALLOW, REDIRECT, or REFUSE 
response based on the sufficiency of a current trust level. In 
some configurations, authorization component 140 dynami- 
cally calculates a current trust level based on the signed 45 
session credentials and environment information. In others, 
authorization component 140 may base its ALLOW, 
REDIRECT, or REFUSE response on a "current" trust level 
previously associated with the signed session credentials. 
Generally, an access request with sufficient current trust 50 
level is ALLOWED and forwarded (14) without further 
authentication. An authorization request without proper 
parameters (e.g., without a specified information resource or 
without a properly secured session credential) may be 
REFUSED. Authorization requests associated with a client 55 
entity that has been blacklisted or for a resource for which 
the associated client entity cannot be authenticated using any 
available method to achieve the required trust level may also 
be REFUSED. For example, a given security policy and 
associated trust level mappings may dictate a REFUSE 60 
response in response to an access request to a sensitive 
resource (such as financial data) by any client entity (even a 
browser supplying the digital certificate for the CFO, and 
therefore presumably operating on behalf of the CEO) if the 
access request is received over a dial-up line and originates 65 
from an unknown number or is received outside of working 
hours. 
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In general, there is an implicit, base level of environment 
inherent in an authenticated trust level; however, in some 
configurations, a particular authorization transaction may 
dig deeper into environment information before responding. 
For example, in configurations providing log-up 
capabilities, an authorization service will typically redirect 
to a login service if the trust level associated with current 
session credentials is insufficient for a requested access. 
However, for sensitive applications in such a configuration, 
an inadequate trust level may result in a REFUSED message 
rather than a log-up REDIRECT depending on the particular 
security policy implemented. 

A REDIRECT response is used to forward the access 
request to login component 120 so that sufficient login 
credentials may be obtained and authenticated to achieve the 
required trust level for the requested access. Note that in 
some configurations, both initial login credentialing and 
credential upgrade are provided using the REDIRECT facil- 
ity. In response to a REDIRECT response (4), gatekeeper/ 
entry handler component 110 redirects (5) browser 170 to 
login component 120. In one configuration, gatekeeper/entry 
handler component 110 issues a client-side redirect via 
HTTP location directive to forward the request to login 
component 120. Parameters such as required trust level, 
requested URL and credential passing method can be 
encoded in the redirect URL and supplied (6) by browser 
170 to login component 120. Alternatively, some parameters 
can be passed (5A) directly (e.g., through a HttpSession 
object) although a stateless configuration is preferred. 

A session token is passed to browser 170 in conjunction 
with the redirect (5) to login component 120. Based on the 
description herein, persons of ordinary skill in the art will 
appreciate a number of suitable mechanisms for passing the 
session token, including those based on cookies and URL 
encoding. Preferably, mechanisms employed are based on 
facilities provided by commercially available browsers (e.g., 
in accordance with HTML 3.x, 4.x or other de-facto 
standards), although customized or plug- in facilities for 
receiving and supplying session token may be employed. In 
one suitable configuration, the session token is cryptographi- 
cally secured and encoded in a cookie placed at browser 170 
using a set cookie directive embedded in the redirect. Other 
configurations may use a less persistent session identifica- 
tion method, such as passing an identifier or session token in 
the redirect URL without storage at browser 170, Still other 
configurations may transmit a session token, a session 
credential, or identifier such as a session handle for storage 
in a medium such as a smart card. In configurations provid- 
ing credential upgrade, persistent session identification 
methods are generally preferred, even for a not yet authen- 
ticated client entity, for consistency of approach. Note that 
although the identity of the client entity may not be authen- 
ticated to a sufficient level of trust, the redirected request 
includes a session token that at least identifies the session. 
Other configurations may omit the binding of session tokens 
to sessions of not yet authenticated client entities, though 
with some increase in complexity of login component 120. 

Browser 170 sends (6) login component 120 a new access 
request using the URL specified in the redirect from 
gatekeeper/entry handler component 110. In configurations 
employing cookies as a medium for passing session tokens, 
the new access request will include the cookie and therefore 
the session token. Note that in configurations in which the 
security architecture controls access to resources in several 
domains, care should be exercised to select a lag or tags for 
the cookie such that it will be provided through normal 
operation of the browser in subsequent accesses to any of the 
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several domains. Persons of ordinary skill in the art will transparent to the user. In some configurations, further 
appreciate suitable tagging techniques, including the use of authentication can be performed by using information 
multiple cookies. Login component 120 receives the access encoded within the certificate to query a certificate authority 
request and determines an appropriate authentication for current status or a lookup to an authentication database 
scheme based on mapping rules that identify those authen- 5 may be performed for more detailed requirements. In an 
tication schemes which are sufficient to achieve a given trust exemplary configuration, the more detailed information 
level. Preferably, the mapping rules are a function of envi- could relate to session environment or could force an 
ronment information. In some configurations, mapping rules additional name/password authentication as part of the cer- 
are implemented as fuzzy sets wherein acceptable authen- tificate authentication chain. In a particular implementation 
tication schemes are a function of required trust level and 10 such facilities can be provided by mapping rule encodings 
environment information. In this way, environment affects that require successful authentication using multiple authen- 
the set of authentication schemes sufficient to meet a trust tication methods to achieve a given trust level, 
level requirement. Once login credentials have been obtained by login corn- 
Generally, mapping rule logic is evaluated before a user ponent 120, they are supplied (11) to gatekeeper/entry 
is challenged to authenticate. Mapping occurs as a function 35 handler component 110 for authentication. In configurations 
of session environment and particulars of the information in which both gatekeeper/entry handler component 110 and 
resource for which access is requested. By evaluating the login component 120 have access to a shared object such as 
minimum trust level required by the target of an access the HttpSession object, login credential passing via the 
request, a service (e.g., a login service such as provided by shared object is suitable. In other configurations, an HTTP 
login component 120) derives a list of potential authentica- 20 POST may be employed. In an exemplary configuration, the 
tion methods. The service then checks current session envi- particular credential passing method is selected as part of the 
ronment against the allowed environment states for each original HTTP redirect (e.g., encoded in the redirect URL) 
potential authentication method to trim the list further. If although other configurations need not allow for a selection 
there is no particular resource for which access is being or may employ other facilities for selection of a credential 
requested (e.g., if a user jumps straight to a sign-on page 25 passing method. 

without requesting an access), the service will proceed Login component 120 also passes control of the access 

according to the lowest level of trust available consistent request back to gatekeeper/entry handler component 110. In 

with session environment. Other configurations may employ an exemplary configuration, login component 120 issues a 

differing default behaviors. new HTTP request (11) specifying the originally requested 

In some configurations, login component 120 queries (7) 30 URL, which has been stored in the HttpSession object. As 

authorization component 140 to identify the set of authen- before, gatekeeper/entry handler component 110 receives 

tication schemes that meet or exceed the required trust level the request. Gatekeeper/entry handler component 110 

given a current environment. In other configurations, the extracts the login credentials from the request or from the 

mapping is performed by login component 120. In either HttpSession object and passes (12) the login credentials to 

case, login component 120 supplies (9) information to 35 authentication component 130 for authentication. Authenti- 

browser 170 to allow the user to select from the suitable cation component 130 authenticates the login credential, and 

authentication schemes and to provide an associated login if successful, queries (13) identification component 150 to 

credential. In some configurations, login component 120 establish a correspondence with a set of entity descriptors 

supplies browser 170 with a login page (e.g., HTML) that that uniquely identifies the requesting entity. In an exem- 

prompts the user for an application specific user ID and a 40 plary configuration, entity descriptor types include: entity id, 

choice of authentication schemes. Interactions with browser system id (e.g., name/password), certificate, enigma id, 

170 depend on the set of credential types that, if smartcard token, name/address, and phone. One or more of 

authenticated, would be sufficient to meet the trust level values may uniquely identify an entity and one or more 

requirement for access to the requested resource. For entity descriptor types may support multiple values (e.g., 

example, if more than one type of credential would be 45 multiple digital certificates, name/password pairs, or phone 

sufficient, login component 120 may interactively allow a numbers per identity). Once the requesting entity has been 

user to select from amongst the credential types (e.g., using identified (14), session parameters are updated (15) and 

any HTML-based dialog). Once a particular credential type session management component 160 supplies (16) .session 

has been selected, login component 120 interacts with credentials. Preferably, session credentials are digitally- 

browser 170 to obtain an instance of the login credential to 50 signed or otherwise cryptographically secured and returned 

establish the identity of the browser user. (17) to gatekeeper/entry handler component 110. 

Some credential types (e.g., usem name/password pairs, Gatekeeper/entry handler component 110 again supplies 

onetime passwords, enigma challenge, etc) may be obtained (18) authorization component 140 with an identifier for the 

through an interactive process in which the user supplies the requested resource (e.g., the requested URL) and an iden- 

login credentials) entry into an HTML form browser 170 55 tifier for the associated session (e.g., the signed session 

POSTs form contents back to login component 120. Others credentials, authorization component 140 responds with an 

(e.g., digital certificates) may be supplied (10) for the client ALLOW, REDIRECT, or REFUSE response based on the 

entity from browser 170, or in some configurations, may be sufficiency the session credentials (and underlying authen- 

obtained from or via an agent or certificate authority. A tication of login credentials) for the trust level required for 

personal digital certificate (such as those issued by 60 the requested access. Login credentials should now be 

Verisign™, Thwate, Entrust or other certificate authority) sufficient for access to the requested resource and an 

may be obtained from a browser 170 using an HTTP ALLOW response is supplied (19) by authorization compo- 

certificate request. Although credentials may be transacted nent 140. Gatekeeper/entry handler component U0 proxies 

in a variety of ways, credentials are typically obtained from the requested access (20, 21) to information resource 191 

a user. Typically, the obtaining is indirect by asking the 65 and streams (22) results back to login component 120. Login 

user's browser to complete the negotiation process. In such component 120, in turn, streams (23) results back to browser 

configurations, certificate-based authentication may be 170. 
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In some embodiments in accordance with the present handle, although other aspects associated with session token 
invention, session continuity is facilitated by supplying a security such as expiration may be updated. In other 
session token to browser 170. For example in one configurations, results (21) are streamed (23A) back to 
configuration, login component 120 supplies a session token browser 170 without an updated session token. In such 
using a set cookie directive encoded with the results 5 configurations, the previously supplied session token 
streamed (23) back to browser 170. In response, browser remains valid until expired or otherwise invalidated. Some 
170 stores the cookie using a tag (typically a filename variations may employ a session token refresh interval, 
encoding). Browser 170 supplies the cookie (and the session Depending on the information resource to which access is 
token) with subsequent access requests based on a corre- requested, previously abided and authenticated login ere- 
J w . .u « * *u *a « dentials may be lnsufi&cient for the trust level requirement 
spondence between the tag and the requested resource. 10 . . . -v. , , t A A . c .l ■ 
„T . „ . i • . 1. jii associated with requested access 1A. As before, authonza- 
Typically, the correspondence is based on the second-level ^ com t {fo Hes ga tekeeper/entry handler corn- 
domain (e.g., sun.com) m which the requested resource is m UQ whh an ^ow, REDIRECT or REFUSE 
hosted, although nth-level domains or other resource iden- reS ponse based on the trust level accorded based on the 
tification and session token associating schemes may be previously obtained and authenticated login credentials and 
employed. In configurations in which the security architec- is on tne trust level requirement associated with requested 
ture controls access to multiple domains across which a access 1A. Advantageously, authorization of individual 
spanning single sign-on is desired, multiple cookies may be access requests is streamlined by the encoding of trust level 
employed. in a cryptographically secured session credential or token. In 

Although the encoding of session tokens using cookies is the case of insufficient credentials, a REDIRECT response is 

presently preferred, in part because cookie facilities are 20 supplied and gatekeeper/entry handler component 110 again 

widely supported and reasonably well accepted, other facili- redirects (5) browser 170 to login component 120. Addi- 

ties may be employed to establish session continuity. For tional login credentials are obtained as described above with 

example, alternative URL encodings and/or custom or plug- reference to initial credentials. Upon successful 

in support for session identifier receipt, storage and supply authentication, access request is proxied (20) and results 

may be employed. Also, some configurations may employ 25 (21) are streamed (23 A) back to browser 170. 

lower-level session identifiers, e.g., as provided by a par- Preferably, gatekeeper/entry handler component 110 sup- 

ticular connection type such as trusted caller id information plies an updated session token using a set cookie directive 

or as associated with a low-level line encryption or virtual encoded with the results streamed (23 A) back to browser 

private network infrastructure. As such facilities are likely to 170. An updated session token, if supplied, resolves to the 

be connection-type specific, it is envisioned that they may be 30 same session object as the session token replaced. As a 

used in conjunction with other session identifier facilities result, session state (including e.g., identity mappings, 

described above, e.g., session tokens encoded in cookies. In authorizations, roles, permissions, environmental variables, 

one configuration, the unique Ethernet MAC address asso- etc.) is maintained through the credential level change, 

ciated with a network interface card may be employed as a However, in the case of a credential upgrade, the session 

session handle. The MAC address is then used to associate 35 object now encodes a login credential successfully authen- 

with a particular set of session credentials maintained by a ticated to achieve a higher trust level. In one advantageous 

central authority. In general the representation of a session configuration, the achieved (higher) trust level is encoded in 

handle can take may forms. a cryptographically secured session token representation as 

Referring again to FIG. 1, subsequent access requests a cookie streamed (23 A) back to browser 170 with results 

(e.g., access request 1A) include a previously assigned 40 (21). 

session token. As described above, gatekeeper/entry handler FIG. 2 illustrates operation of an exemplary security 
component 110 uses the session token, if provided to resolve architecture providing a single sign-on facility with trust 
a session object containing session credentials, and to deter- level mapping to authentication requirements. As before, an 
mine whether previously authenticated credentials are suf- access request is received (201) from a client entity. If the 
ficient for the requested access. As described above, autho- 45 request does not contain a session identifier (e.g., a session 
rization component 140 may be queried using session key or token) or if the request can otherwise be reliably 
credentials and an identifier for the requested resource to associated with a session maintained by the security 
determine sufficiency of previously authenticated creden- architecture, a new session is created (202). A trust level 
tials. In some configurations, sufficiency is determined using requirement is determined for access to the requested 
trust level mappings as described above. Depending on the 50 resource in the context of the requesting session environ- 
information resource to which access is requested, and in ment. In some configurations, as described above, the deter- 
some configurations depending on current session environ- mination is performed by an authorization service such as 
ment information, access request 1 A may or may not have authorization component 140. Given a trust level 
associated previously authenticated credentials sufficient to requirement, current session credentials are evaluated (203) 
support the requested access. In the case of an access request 55 in the context of session environment information to deter- 
1A having a trust level requirement commensurate with mine whether the previously supplied login credentials are 
previously obtained and authenticated credentials (i.e., an sufficient to achieve the required trust level. In one advan- 
access request for which no additional credentials need be tageous realization of session credentials and tokens, a 
obtained via login component 120), the access request is cryptographically secured encoding of trust level allows 
proxied (20) and results (21) are streamed directly (23A) 60 authorization to be confirmed without involvement of an 
back to browser 170. In some configurations, gatekeeper/ authentication service (e.g., with reauthentication of login 
entry handler component 110 supplies an updated session credentials). In the case of a newly created (202) session, the 
token using a set cookie directive encoded with the results authorization evidenced by session credentials will typically 
streamed (23 A) back to browser 170. An updated session be insuflBcient, although some security policies may allow 
token, if supplied, resolves to the same session object as the 65 anonymous access to certain resources, 
session token replaced. For example, in some For a pre-existing session, i.e., for an access request that 
configurations, both session tokens encode a same session can be reliably associated with a persistent session by a 
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cryptographically secured session token or otherwise, ses- 140. A trust level requirement is mapped (209) to at least one 
sion credentials may or may not be sufficient for access to authentication scheme sufficient to achieve the requirement 
the currently requested resource. For example, after a first based on current trust level mappings and, if employed in the 
access, the identity of an entity accessing resources con- mapping rules, based on current environment information, 
trolled by the security architecture will be authenticated to a 5 Assuming that at least one authentication scheme is avail- 
trust level sufficient for that access. Depending on the trust able that, if successful, will support the required trust level, 
level requirements of a subsequent access and, in some login credentials of that type are obtained (2 10) for the entity 
configurations, depending on then current trust level map- and authenticated (211). Some credential types (e.g., 
ping rules and environment information, the level of trust username/password pairs, onetime passwords, enigma 
associated with a current session (e.g., as evidenced by 10 challenge, etc) may be obtained through an interactive 
current session credentials) may or may not be sufficient for process in which a principal (e.g., a human user) supplies the 
the subsequent access. In situations for which a current level credential(s) entry in an HTML form and POSTs form 
of trust (e.g., resulting from prior authentication of login contents back to the credential gathering service. Others 
credentials for an entity associated with the session) is (e.g., certificates) may be obtained for the client entity from 
sufficient for later access to the same or to another infor- 15 an agent or authority. For example, a personal digital cer- 
mation resource, access is allowed without additional tificate (such as those issued by Verisign™ , Thwate, Entrust 
authentication. For example, in some security architectures or other certificate authority) may be obtained from a 
in accordance with the present invention, the security archi- browser using an HTTP certificate request. In some 
tecture proxies (204) the request to the requested informa- configurations, a choice of credential types may be provided 
tion resource and streams (205) a resulting response back to 20 and user may select from a set of credential types sufficient 
the requesting client entity. for the requested access. Once appropriate login credentials 
As described elsewhere herein, sufficiency of current have been obtained and authenticated, the session corre- 
session credentials is determined using mapping rules that, sponding to the requested access is updated (213) to reflect 
in some realizations, include environment information. In the new authenticated session credentials. The now suffi- 
general, current session credentials may be insufficient (1) 25 ciently authorized request is proxied (204) and results are 
because the identity of the requesting client has not yet been streamed back (205) to the requesting client entity. Updated 
authenticated (e.g., in a first access situation), (2) because of or refreshed session credentials are typically supplied as a 
a higher trust level requirement for the requested access, or session token (e.g., a cookie) encoded with the streamed 
(3) because of a change in mapping rules or environment results. 

that causes a previously sufficient credential no longer be 30 FIG. 3 illustrates interactions between functional compo- 

sufficient for a particular trust level. Whatever the reason for nents in an exemplary functional decomposition of a secu- 

the insufficiency, a request corresponding to a session and rity architecture. An on-line order processing transaction is 

client entity that is insufficiently authenticated, and that is exemplary and functional boundaries are merely illustrative, 

therefore not authorized, is passed to a facility for obtaining Based on the description herein, a wide variety of suitable 

credentials of a type that, if authenticated, will support the 35 enterprise information environments and functional decom- 

required trust level. positions in accordance with the appended claims will be 

Typically, session credentials and/or an associated session appreciated by persons of ordinary skill in the art. 
token encode an expiration time (see description, below, of In the configuration of FIG. 3, application and central 
FIG. 4). In such configurations, a previously sufficient security portions (321 and 322, respectively) of the security 
session credential is insufficient after its expiration. In some 40 architecture are illustrated. Of note, functional components 
configurations, session credentials are periodically refreshed of application security portion 321 are typically hosted as 
by reauthentication of the underlying login credentials. For services on a first server environment, while functional 
example, in one implementation, a presented session token components of central security portion 322 are hosted as 
indicating expiration in less than five (5) minutes causes the services on a second server environment. In this way, most 
security architecture to reauthenticate (not shown) underly- 45 interactions amongst functional components occur within a 
ing login credentials stored in a corresponding SessionOb- single server environment and do not require network trans- 
ject (e.g., under the private key of authentication component actions. In the configuration of FIG. 3, credentials associated 
130). Reauthentication typically results in a new session with a calling component (e.g., framework credentials asso- 
credential and associated trust level. Depending on then ciated with application security framework 303 or applica- 
instant mapping rules, the associated trust level may or may 50 tion credentials associated with order management service 
not be sufficient. Also, reauthentication may fail if the login 312) are used to establish sufficient authorization for net- 
credentials have been invalidated, revoked or if the login work transactions. Other configurations may be employed, 
credentials have expired. Assuming that reauthentication of however, the relatively small number of network transac- 
login credentials is successful, updated session credentials tions(e.g., authentication transaction 331 and optional value 
are issued, for example, by authentication component 130 55 passing transaction 332) tends to improve performance of 
and supplied (e.g., as a cookie encoded session token) to the the security architecture. Of note, authentication transaction 
client entity e.g., browser 170). 331 need only be performed on login credential authentica- 

Referring again to FIG. 2, a request corresponding to a tion (e.g., at initial sign-on or credential upgrade) or reau- 
session not authorized for a requested access is redirected thenticated (e.g., to refresh session credentials). Value pass- 
(206) to a credential gathering service (e.g., login compo- 60 ing transaction 332 provides an optional facility for passing 
nent 120). The credential gathering service receives (207) values amongst multiple components of a distributed appli- 
the redirected access and obtains (208) a trust level require- cation (e.g., a distributed implementation of order manage- 
ment for the requested access. In some configurations, the ment service 312) wherein application credentials are used 
trust level requirement may be passed with the redirected to mediate storage and retrieval of values in a central 
access or otherwise associated with the redirected access, in 65 registry. 

others the trust level requirement may be re-obtained from User 301 interacts with browser 302 to place an order with 

an authorization service such as authorization component order management service 312. An application security 
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framework 503 receives an access request including the 
order and, operating in conjunction with a variety of other 
services, provides a single sign-on facility substantially as 
described above. If the order does not include a session 
token or cannot be otherwise associated with corresponding 5 
valid session credentials, then session credentials are 
obtained. As illustrated in FIG. 3, session credentials are 
obtained using login credentials (e.g., a username/password 
pair, a digital certificate, etc.) Typically, an access request 
without session credentials will not have associated login JQ 
credentials. As a result, and default login credentials (e.g., 
identity«anonymous) are used during initial phases of a 
single sign-on process. Nonetheless, in some configurations, 
login credentials may be provided with an initial access 
request. More typically, an initial access request is received 
by application security framework 303 without session 15 
credentials or without prior presentation and authentication 
of login credentials sufficient to access the requested 
resource. In response to credential gathering operations, a 
subsequent request is made with login credentials that 
purport to be sufficient, if authenticated, to meet the trust 20 
level required for access to order management service 312. 
In such a case, session credentials are obtained by passing 
login credentials to a central security framework 304. 

Authorization of application security framework 303 for 
access to components of the central security portion 322 is 25 
checked by query to central authorization service 306. 
Assuming that framework credentials evidence sufficient 
authorization, login credentials are authenticated by central 
authentication service 307. Central authentication service 
307, in turn, interacts with central principal registry 310 to 30 
establish the identity and group membership of user 301 and 
with central session registry 311 to create a persistent 
session for subsequent accesses by user 301. Particulars of 
the request are logged to central audit service 308 and, if 
authentication was successful, session credentials are 35 
returned to application security framework 303. 

Signed session credentials are presented to application 
authorization service 313 together with an identifier for the 
requested resource and optionally with an identifier for a 
particular function or facility of the requested resource. In 40 
response, application authorization service 313 checks the 
authorization of the principal (e.g., of user 301) associated 
with the session credentials to access the requested resource. 
Application authorization service 313 interacts with appli- 
cation resource registry 314 to identify trust level require- 45 
ments for the requested resource (and in some 
configurations, for a particular function or facility of the 
requested resource) and determines the sufficiency of a 
current trust level evidenced by the session credential. Note 
that trust level is assessed by inspection of the session 50 
credential and without interaction with an authentication 
service. In some configurations (e.g., as illustrated in FIG. 
3), group membership is also evaluated as part of the 
authorization check. 

If the signed session credentials indicate that the request- 55 
ing entity, e.g., browser 302 on behalf of user 301, is 
sufficiently authorized to access order management service 
312, a Create Order request is passed to order management 
service 312 and order processing proceeds in accordance 
with normal handling thereof. Additional accesses may be 60 
required, e.g., to select delivery options or to confirm some 
aspect of the order. Assuming that the additional accesses do 
not require a higher trust level, they will be passed to order 
management service 312 based on the correspondence of 
session credentials with trust level requirements. 65 

If an exception is thrown due to insufficient authorization, 
e.g., if the signed session credentials do not indicate that the 
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requesting entity is sufficiently authorized to access order 
management service 312, a login credential gathering pro- 
cess is initiated. Based on the required trust level and on 
rules that encode the sufficiency of authentication schemes, 
a login credential is obtained from user 301 and/or browser 
302. The obtained login credential is of a type that, if 
authenticated, is sufficient to meet the trust level requirement 
for access to order management service 312. Aspects of an 
exemplary credential gathering process are described in 
greater detail above. However, as an example, FIG. 3 
illustrates the obtaining of a username/password pair. Once 
login credentials are obtained, they are passed to central 
security framework 304 (as described above) for authenti- 
cation by central authentication service 307 so that session 
credentials can be obtained, the requested access can be 
authorized, and the order processing initiated. Signed ses- 
sion credentials, typically embodied as a cryptographically 
secured session token that may be stored as a cookie, are 
passed back to browser 302 with results of the requested 
access. In this way, subsequent access requests are identified 
as part of a session and authorization may be quickly 
confirmed without unnecessary reauthentication. 

Some configurations in accordance with the present 
invention employ session credentials as a mechanism for 
evidencing prior authentication of obtained login credentials 
and for binding individual transactions to a particular ses- 
sion. In some configurations, session credentials are also 
employed in a session token form advantageous for trans- 
actions external to the security architecture. In an exemplary 
realization, session tokens are encoded for supply to brows- 
ers as cookies. FIG. 4 illustrates relationships between 
exemplary login credential, session credential and session 
token objects. 

As described above, login credentials (e.g., represented in 
a form such as exemplary login credentials structure 410) 
are obtained for a client entity. Typically, login credentials 
encoded in login credentials structure 410 are obtained from 
a principal via browser client and serve as evidence that the 
principal (e.g., a human user) is entitled to a particular 
identity. Accordingly, login credentials structure 410 
encodes a userld and a domainld within which the userld 
should uniquely correspond to a principal. Specific login 
credentials, e.g., a password, a certificate, results of a 
biometric process, a response to an Enigma challenge or 
results of a smart card interrogation, etc. are encoded in 
login credentials structure 410, as a tagged value. An authen- 
ticationScheme is specified and creation time may be 
encoded to limit replay attacks. In the implementation of 
FIG. 4, login credentials structure 410 is encrypted using the 
public key of an authentication service (e.g., of authentica- 
tion component 130). Because the key is public, any 
component, even untrusted components may encrypt login 
credentials for provision to authentication component 130, 
while only authentication component can decrypt the 
encrypted login credentials using its private key. In some 
configurations, secure transfer protocols, e.g., SSL, are 
employed to secure login credentials between a client entity 
such as browser 170 and the security architecture while 
encryption with a public key of an authentication service is 
performed within the security architecture, e.g., at login 
component 120. In other configurations, encryption with a 
public key of an authentication service may be performed at 
the client entity. 

If the encrypted login credentials provided to an authen- 
tication service are determined to be authentic, session 
credentials are issued. In the implementation of FIG. 4, 
session credentials are embodied in a form such as exem- 
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plary session credentials structure 420. Encrypted and clear 
text portions (421 and 422) of session credentials structure 
420 allow contents of the session credential to be read by 
anyone and changed by no one (except the authentication 
service possessing a private key). Contents of encrypted 
portion 421 correspond to that clear text portion 422 but are 
encrypted using the private key of the authentication service 
(e.g., of authentication component 130). Of note, principal 
ids, authorizations and other contents encoded in the session 
credential may be read by components of the security 
architecture, and in some embodiments by components 
external to the security architecture. Such components can 
verify the authenticity of information stored in clear text 
portion 422 using encrypted portion 421 and a public key 
corresponding to the private key of the authentication ser- 
vice. Of note, the information contained in a session cre- 
dential is generally not sensitive. What is sensitive is the 
state of the information. Therefore, security architectures 
employing facilities described herein ensure that informa- 
tion contained in the session credential is provably constant 
once set by an authentication service. By using the public 
key of the authentication service, which will in general be 
freely available, together with the encrypted information, 
any application can read the information (e.g., in free text) 
and ascertain that the session credential was created by the 
authentication service and that the session credential has not 
been tampered with. Assuming that the authentication ser- 
vice's private key has not been compromised, tampering 
with the session credential will result in a decryption failure. 

In an alternative implementation (not shown), session 
credentials may be digitally signed and verified by a public 
key corresponding to a private key. In such an alternative 
implementation, the digital signature also allows contents of 
the session credential to be read by anyone and changed by 
no one. For some configurations, the implementation of FIG. 
4 is preferred because encrypted portion 421 can be used as 
an externally supplied session token. Such a session token 
representation is a compact representation of the session 
credential particularly appropriate for encoding as a cookie 
placed at a browser and returned with subsequent access 
requests. 

Referring again to session credentials structure 420, a 
session id, a principal id, a trust level, group ids, a creation 
time and an expiration time are encoded in both in encrypted 
portion 421 and clear text portion 422. The session id is a 
unique identifier for a persistent session maintained by the 
security architecture. In implementations in which credential 
upgrade is provided or in which a session credential expi- 
ration and refresh is provided, multiple successively issued 
session credential instances may encode the same session id 
and correspond to the same persistent session. Principal id 
encodes an identifier for a principal to which the security 
architecture has resolved login credentials. For example, a 
login credential including a username jdoe and a password 
corresponding to jdoe may be resolved by the security 
architecture to a unique principal id associated with John. Q. 
Doe of the shipping and receiving department, having an 
employee badge number of 12345, etc. 

In some embodiments, a trust level encodes the authori- 
zation level to which a principal has been authenticated. In 
such embodiments, the encoded trust level serves as a basis 
for evaluating whether a principal associated with the ses- 
sion credentials has been authenticated to a sufficient level 
for access to a requested resource. For example, a trust level 
of 5 may be sufficient for access to information resources 
having a trust level requirement of 5 or less. Trust levels 
offer an attractive decoupling of authorization levels and 
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authentication methods as described elsewhere herein. 
However, in some embodiments, an authorization encoding 
may establish that a principal has been authenticated using 
a particular authentication mechanism. In either case, an 

5 authorization (e.g., encoded as a trust level) in a crypto- 
graphically secured session credential allows the security 
architecture to authorize accesses based on prior authenti- 
cation of a login credential and without involvement of the 
authentication service. Group ids can be used to grant or 

10 limit authorization scope based on group membership. 
Typically, session credentials serve as evidence of prior 
authentication and authorization for multiple accesses to 
information resources controlled by the security architec- 
ture. However, session credentials may be replaced on a 

is login credential upgrade as described elsewhere herein. In 
addition, session credentials of limited temporal validity 
may be refreshed by periodic replacement. In the configu- 
ration of session credentials structure 420, creation time and 
expiration time allow the security architecture to improve 

20 resistance to replay attacks. Session credentials typically 
have a relatively short expiration time (e.g., 15 minutes from 
creation or less) and underlying login credentials will be 
reauthenticated prior to expiration of the session credential. 
Assuming that the underlying login credentials, which are 

25 stored under the public key of authentication component 
130, remain valid, authentication component 130 will issue 
a replacement cryptographically secured session credential 
(e.g., as session credentials structure 420). Depending on 
then current trust level mappings and, in some 

30 configurations, depending on then current environment 
parameters, the authorization accorded by the security archi- 
tecture and encoded as a trust level may differ from that 
encoded in the session credential replaced. If a principal id 
or login credential has been revoked, reauthentication may 

35 fail and a user may be prompted to supply a sufficient login 
credentials as described elsewhere herein. Session id and 
principal id will typically remain the same for successive 
session credentials associated with a single persistent ses- 
sion. 

40 As previously described, one advantage of the approach 
employed in session credentials structure 420 is that 
encrypted portion 421 may also be employed as a compact 
session token representation 430 of session credential for 
use as a cookie. In one embodiment in accordance with FIG. 

45 4, encrypted portion 421 is a string encoded representation 
of approximately 200 characters which may be placed at a 
browser (e.g., via transfer 5, 23 or 23A of FIG. 1) using a set 
cookie directive. 
Exemplary Implementations 

50 In an exemplary embodiment, at least some of the above- 
described components are implemented as servlets execut- 
able in the context of a commercially-available web server 
environment. For example, the Java™ Embedded Server 
(JES) architecture with extensions for certificate handling, 

55 HyperText Transfer Protocol (HTTP), Simple Network 
Management Protocol (SNMP), Secure Sockets Layer 
(SSL), extensible Markup Language (XML) grammar pro- 
cessing and security Access Control List (ACL) support 
available from Sun Microsystems, Inc. is one suitable envi- 

60 ronment. Java and all Java-based marks and logos are 
trademarks or registered trademarks of Sun Microsystems, 
Inc. in the United States and other countries. 

In general, the description herein is focused on aspects of 
a security architecture, rather than on peculiarities of a 

65 particular implementation environment. It is envisioned thai 
security architectures in accordance with the teachings of the 
present invention may be implemented in the context of 
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many commercially-available networked information ser- 
vice environments, including web server environments, as 
well as in custom environments and environments that in the 
future will be developed. However, to facilitate an under- 
standing of broad concepts using a specific exemplary 5 
environment, and without limitation, the description herein 
may include terminology specific to the Java Embedded 
Server (JES) architecture. Nonetheless, based on this 
description, persons of ordinary skill in the art will appre- 
ciate implementations suitable for other environments. The 30 
scope of the invention, as defined by the claims that follow, 
is not limited to any specific implementation environment. 

While the invention has been described with reference to 
various embodiments, it will be understood that these 
embodiments are illustrative and that the scope of the 35 
invention is not limited to them. Many variations, 
modifications, additions, and improvements are possible. 
For example, the set of authentication schemes described 
herein is illustrative and embodiments in accordance with 
the present invention may include others, including those 2 o 
that may be hereafter developed. If employed, rules mapping 
trust levels to authentication schemes may be encoded in a 
variety of ways depending on the particular implementation. 
In general, such mapping rules may be encoded as static or 
dynamic table associating trust level to authentication 2 5 
schemes. Alternatively, mapping rules may be encoded as 
predicates or in other declarative forms. Mapping rules may 
be encoded in a weighted logic or fuzzy set form. 
Additionally, particular mappings may depend environment 
information. Furthermore, evaluation of mapping rules may 30 
be performed in a variety of functional components such as 
an authorization service, a credential gathering service or a 
gatekeeper. Session continuity may be provided using cryp- 
tographically secure session tokens passed as cookies or by 
other mechanisms. 35 

In some configurations, a session token is a compact 
encrypted representation of at least selected contents of a 
session credential. Other compact representations corre- 
sponding to a session credential may be employed. 
Alternatively, the same representation of session credentials 40 
may be employed both within the security architecture and 
outside the security architecture (e.g., at a browser or other 
client). Suitable contents of a session credential (and session 
token, if employed) will be appreciated by persons of 
ordinary skill in the art based on the description herein of 45 
specific examples. 

More generally, plural instances may be provided for 
components described herein as a single instance. Finally, 
boundaries between various components, services, servlets, 
registries and frameworks are somewhat arbitrary, and par- 50 
ticular operations are illustrated in the context of specific 
illustrative configurations. Other allocations of functionality 
are envisioned and may fall within the scope of claims that 
follow. Structures and functionality presented as discrete 
components in the exemplary embodiments) may be imple- 55 
mented as a combined structure or component. These and 
other variations, modifications, additions, and improve- 
ments may fall within the scope of the invention as defined 
in the claims that follow. 

What is claimed is: 60 

1. A method of determining sufficiency of a credential 
type for access to an information resource, the method 
comprising: 

establishing a correspondence between a session and an 
access request targeting the information resource; 55 

establishing a trust level requirement for access to the 
information resource; and 
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evaluating correspondence of one or more credential 
types with the trust level requirement for access to the 
information resource and with environment informa- 
tion associated with the session. 

2. A method as in claim 1, 

wherein one or more authenticated credentials of the one 
or more credential types are associated with the ses- 
sion; and 

wherein the correspondence evaluating includes deter- 
mining whether at least one of the one or more authen- 
ticated credentials is sufficient to achieve the trust level 
requirement given the environment information. 

3. A method as in claim 2, further comprising: 

if at least one of the one or more authenticated credentials 
is sufficient to achieve the trust level requirement given 
the environment information, allowing the requested 
access; and 

otherwise, obtaining and authenticating a sufficient cre- 
dential before allowing the requested access. 

4. A method as in claim 1, 

wherein the correspondence evaluating includes deter- 
mining a set of the credential types sufficient to achieve 
the trust level requirement given the environment infor- 
mation. 

5. A method as in claim 4, further comprising: 
obtaining at least one credential of a type selected from 

the set of sufficient credential types; 
authenticating a client entity thereby; and 
performing the requested access on behalf of the client 

entity. 

6. A method as in claim 1, 

wherein the correspondence evaluating includes evaluat- 
ing a mapping rule encoding suitable credential types 
as a function of trust levels and environment param- 
eters. 

7. A method as in claim 1, 

wherein the session correspondence establishing includes 
use of a cryptographically secured session token 
encoded with the access request to resolve the session 
and the environment information. 

8. A method as in claim 1, further comprising: 
coincident with receipt of the access request, updating the 

environment information associated with the corre- 
sponding session. 

9. A method as in claim 1, 

wherein the environment information includes one or 
more of connect location, access request time, access 
request date, session start time, session start date, client 
type and client capabilities. 

10. A method as in claim 1, 

wherein the session includes a dial-up connection; and 
wherein the environment information includes one or 
more of connection speed and low-level line encryp- 
tion. 

11. A method as in claim 1, wherein the environment 
information includes one or more of source identifier and 
signaling type. 

12. A method as in claim 1, 

wherein the session includes a network connection; and 
wherein the environment information includes one or 
more of source network, source node, Virtual Private 
Network (VPN) low-level encryption and routing infor- 
mation. 
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13. A method as in claim 1, 

wherein the set of the credential types includes one or 
more of a usemname password pair, digital certificate, 
an encrypted credentials based on asymmetric, 
symmetric, public, private, or secret key technology, a 
one-time password, a biometric credential based on 
retinal scan, voice print, or finger print, and a posses- 
sion based credential embodied in a smart card, Enigma 
card or physical key. 

14. A method as in claim 1, 

wherein the trust level requirement establishing includes 
querying an authorization service with a resource iden- 
tifier for the information resource targeted by the access 
request and with a session identifier for the correspond- 
ing session. 

15. A method as in claim 1, embodied as a computer 
program product including functionally descriptive informa- 
tion for directing a processor to perform the correspondence 
establishing, the trust level requirement establishing, and the 
evaluating, the computer program product encoded by or 
transmitted in at least one computer readable medium 
selected from the set of a disk, tape or other magnetic, 
optical, or electronic storage medium and a network, 
wireline, wireless or other communications medium. 

16. A method of operating a security architecture, the 
method comprising: 

matching an access request of a client entity with a 
corresponding session, the access request targeting a 
first of plural information resources and the session 
having an associated one or more session parameters 
affecting sufficiency of credential types; 

determining a set of one or more credential types suffi- 
cient for access to the first information resource, the 
determining based, at least in part, on the one or more 
session parameters; 

if an authenticated credential associated with the session 
is of one of the sufficient credential types, then allowing 
access to the first information resource; and 

otherwise, 

obtaining a new credential and authenticating the client 
entity thereby, the obtained credential being of one of 
the sufficient credential types; and 

allowing access to the first information resource. 

17. A method as in claim 16, wherein the determining of 
sufficient credential types includes: 

obtaining a trust level requirement associated with the 
first information resource; 

selecting only those credential types sufficient, if 
authenticated, to achieve the trust level requirement 
given current values of the one or more session param- 
eters. 

18. A method as in claim 16, wherein the determining of 
sufficient credential types includes: 

evaluating decision logic encoding the set of sufficient 
credential types as a function of the session parameters 
and particular one of the information resource for 
which access is requested. 

19. A method as in claim 17, wherein the decision logic 
is encoded at least partly as one of: 

mapping rules; 
fuzzy sets; and 

session parameter-based trust level discounts; and 

an enumeration of trust level and session parameter 

minima corresponding to individual of the credential 

types. 
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20. A method as in claim 16, wherein the determining of 
sufficient credential types includes: 

evaluating decision logic encoding the set of sufficient 
credential types as a function of the session parameters 
and a trust level requirement associated with the tar- 
geted information resource. 

21. A method as in claim 16, 

wherein the one or more session parameters are indicative 
of temporal, locational or connection-related states of 
the matched session. 

22. A method as in claim 16, 

wherein the client entity includes a browser; and 
wherein the matching of the access request with the 
session includes use of a cryptographically secured 
session token encoded in cookie supplied to the 
browser. 

23. An information system comprising: 

plural information resources hosted on one or more serv- 
ers coupled via a communication network to a client 
entity, the plural information resources having indi- 
vidualized authentication requirements; and 

an access control facility common to the plural informa- 
tion resources, the common access control facility 
obtaining a credential for the client entity and authen- 
ticating the client entity thereby; 

wherein, in response to a request for access to a first of the 
information resources, the common access control 
facility evaluates, based in part on current parameters 
of a corresponding persistent session, sufficiency of 
associated authenticated credentials for access to the 
first information resource. 

24. An access control facility for providing a single 
sign-on for sessions that potentially include accesses to 
plural information resources having differing security 
requirements, the access control facility comprising: 

an application proxy for receiving an access request 
targeting one of the information resources, associating 
the access request with a session, and selectively 
proxying the access request; 

means responsive to the application proxy for evaluating 
sufficiency of credential types based on then current 
parameters of the session and on a trust level require- 
ment of the targeted information resource, the applica- 
tion proxy proxying the access request if at least one 
sufficient credential is associated with the session. 

25. An access control facility as in claim 24, further 
comprising: 

credential gathering means responsive to an insufficient 
zero or more credentials associated with the session, 
the credential gathering means obtaining a credential of 
type sufficient, if authenticated, to achieve the trust 
level requirement of the targeted information resource 
given then current parameters of the session. 

26. An access control facility as in claim 24, embodied as 
a computer program product encoded by or transmitted in at 
least one computer readable medium selected from the set of 
a disk, tape or other magnetic, optical, or electronic storage 
medium and a network, wireline, wireless or other commu- 
nications medium. 
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